Data transmission rates necessary for modern, high performance computer printers and peripherals are much higher than early model printers. For example, early computer printers using daisy wheel or dot matrix impact printing technologies relied upon a limited number (e.g., 128) of character codes (typically ASCII) transmitted by a host computer to generate and print characters. Further, the printing rate of such early impact printers (on the order of several characters per second) did not require a high data transmission rate.
More advanced dot matrix printers having limited graphics functions typically did not require great data bandwidth, as resolution (dots per inch) was limited. Simple serial (e.g., RS-232) or parallel interfaces (e.g., Centronics.TM. or the like) were more than suitable for these early printing devices.
However, newer printers, (e.g., laser printers or the like) are capable of more complex graphics functions, greater print speeds, and two-way communication between the device and a host computer (e.g., network applications or the like). In addition, new peripherals have been developed for graphics use (e.g., scanner or the like) which require transmitting large amounts of data to a host computer. Thus, typical prior art parallel port interfaces (e.g., Centronics.TM. or so-called LPT ports or the like) have proved to be a bottleneck in data transmission from a host computer to a high performance printer, or from a scanner to a host computer.
In addition, newer, more sophisticated peripheral devices such as laser printers, have increased needs for two-way communication between a host computer and the peripheral, such as in network printer applications. Prior art parallel port interfaces were not suitably adapted to readily provide such two-way communication.
New parallel interface standards have been adapted to improve over the prior art Centronics.TM. ports. One example of such a standard is the IEEE P1284 specification or the Industry Standards Associate (ISA) Extended Capabilities Port (ECP) protocol both of which are incorporated herein by reference. These new protocols may be provided in a communications port which is backwardly compatible with earlier communications standards (e.g., Centronics.TM. or the like). The ECP protocol allows for Direct Memory Access (DMA) to improve data transmission rates. In addition, the ECP protocol may be provided with Run Length Encoding (RLE) to compress data and further increase data transmission rates.
RLE can compress up to 128 bytes of identical data into two bytes of information, thus providing up to a 64:1 compression ratio. In printing and scanning applications, repetitive data bytes are common. For example, in alphanumeric printing applications, a repeated number of ASCII characters may be transmitted representing blank spaces (i.e., ASCII 32, or 0010000). In graphics applications, where raster scanning techniques may be used to represent individual pixels or dots of information, large amounts of repetitive pixels may be transmitted to draw, for example, a straight line, or represent a large blank area. RLE compresses the data into a command byte representing the number of times the byte is repeated, and a data byte, which represents the byte to be repeated.
To decompress the data, the process is reversed. The command byte is received, and the peripheral device (or computer host, depending on direction of data transmission) repeats the following byte the number of times indicated by the command byte. In the ECP protocol, the computer host or peripheral distinguishes from command and data bytes by monitoring the HostAck (nAutoFd) pin (pin number 14). When the HostAck pin is high, the information transmitted on pins 2 through 9 is a data byte. When the HostAck pin is low, the information transmitted on pins 2 through 9 is a command byte. If the most significant bit (MSB) of the command byte is low, the command is a run length count. Thus, only seven bits are available for a maximum run length count of 128.
Although the ECP protocol provides for the use of run length encoding, the protocol does not set forth an efficient and economical technique for performing run length encoding. An intuitive approach to performing such encoding might comprise storing data within a memory, and compressing the data into RLE format before transmission by performing encoding operations on the data in memory. However, such a technique is time consuming and may require additional hardware or operation steps.
Thus, it remains a requirement in the art to provide an economical and efficient technique for implementing run length encoding in the ECP protocol.